1. Field of the Invention
The invention relates to software systems particularly with respect to coordination of software feature installation in separate software systems.
2. Description of the Prior Art
Computer systems normally include plural separate software systems exemplified by the System Software (including the Operating System (OS), System Libraries and Utility programs), Application software (including OEM as well as user), and for some Medium to Large Scale systems, Special Purpose Processor (SPP) microcode. An example of an SPP would be the Task Control Unit (TCU) and I/O Unit (IOU) which are part of the I/O Module (IOM) on some of the A-Series and ClearPath systems manufactured by Unisys Corporation of Blue Bell, Pa. (e.g. A18, NX4800).
The IOU is a logical component of the IOM responsible for managing I/O requests sent by OS software. The TCU is the logical component of the IOM responsible for managing task switching and events. In such computer systems there is generally a problem with respect to the release and/or installation of such software systems (e.g., OS software and SPP microcode).
The IOU is a logical component of the IOM responsible for managing I/O requests sent by OS software. The TCU is the logical component of the IOM responsible for managing task switching events. In such computer systems there is generally a problem with respect to the release and/or installation of such software systems (e.g., OS software and SPP microcode).
Normally, the release and/or installation of OS software and SPP microcode can occur independently. If, however, one or more newly added system features require OS software and SPP microcode functionality, problems arise in the coordination of release and installation of the separate software systems. The coordination effort is further complicated when the release and installation procedures differ.
With respect to release problems, it is more often than not, that OS software development and SPP microcode development are performed by different engineering groups. These groups develop release procedures, release identification methods, release media, project schedules and the like, that best satisfy their requirements. Because of the inherent differences between the development of high-level OS software compared to SPP specific microcode, the release mechanisms are seldom the same.
Whenever a new system feature is introduced requiring new releases from both the OS software and the SPP microcode, the following constraints must be considered.
1. The release dates for both the OS software and SPP microcode must be the same. Since software and microcode are independently developed, no advantage is achieved by the early completion of either the OS software or the SPP microcode. PA1 2. The release of additional new features that are unique to either the OS software or SPP microcode must be delayed until both releases are ready. PA1 3. The release of problem fixes that are unique to either the OS software or SPP microcode are delayed until both releases are ready. PA1 4. Regression testing is delayed until both releases are ready. PA1 5. Individual release documentation is complicated by the addition of release interdependency descriptions. PA1 1. If release interdependencies are not properly documented or are misinterpreted by those responsible for the installation, the wrong release levels may be installed or interdependent releases may be omitted. This may result in longer system interruptions and potentially require that a previously installed release be backed out until the interdependent release is obtained. PA1 2. Even though an installation completes successfully, if an interdependent release was omitted, it may not be immediately detected. The system will resume normal operations until the new system feature is invoked. PA1 3. Release and installation of OS software and SPP microcode must be coordinated whenever one or more mutually supported system features are added. PA1 1. Optional and required system features may be developed and released independently by software development groups such as the OS and SPP development organizations. PA1 2. Support releases, for example, OS or SPP, (which may contain bug fixes) may now include new optional and required feature support without the need to synchronize such releases. PA1 3. Incompatibility resulting from feature content between OS and SPP releases is immediately detected and reported by the OS during initialization.
With respect to installation problems, it is not unusual for OS software and SPP microcode installation procedures to differ. Systems often allow OS software and SPP microcode to be independently installed. System interruptions are minimized if only one or the other requires a new support release to be installed. Whenever a new system feature is introduced and that feature requires new releases from both the OS software and SPP microcode, the following installation constraints must be considered.
Although the above problems were described in terms of OS software and SPP microcode, it is appreciated that these problems arise in any system that includes a plurality of separate software entities required to support a particular new feature. Similarly, the below-described invention, that solves the problems, although explained in its best mode embodiments with specific software entities, it is appreciated that the invention is applicable to any plurality of software entities required to support a system feature. Specifically, the invention will be described in terms of OS software and SPP microcode such as a TCU for an IOM. In the Unisys Corporation A-Series computer systems the OS is referred to as a Master Control Program (MCP). The-invention may also be applied to the MCP and an IOU for the IOM.
Additionally, the invention may be applied between OS software and a System Library, between two user applications or between any independent software entities capable of exchanging data in the manner to be described by its best mode embodiments.